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METHODS AND APPARATUSES FOR WIRELESS PACKET HANDLING USING 
MEDIUM ACCESS CONTROL ACTION TABLES 

BACKGROUND 

[0001] The present invention relates generally to wireless communication systems 

and, more particularly, to systems and methods for handling data packets to address time 
sensitivity and quality of service (QoS). 

[0002] Technologies associated with the communication of information have evolved 

rapidly over the last several decades. For example, over the last two decades wireless 
communication technologies have transitioned from providing products that were originally 
viewed as novelty items to providing products which are the fundamental means for mobile 
communications. Perhaps the most influential of these wireless technologies were cellular 
telephone systems and products. Cellular technologies emerged to provide a mobile 
extension to existing wireline communication systems, providing users with ubiquitous 
coverage using trad itional circuit-switched radio paths. More recently, however, wireless 
communication technologies have begun to replace wireline connections in almost every area 
of communications- For example, wireless local area networks (WLANs) are rapidly 
becoming a popular alternative to the conventional wired networks in both homes and offices. 
[0003] Circa 1990, the EEEE 802 standards committee formed the 802.1 1 Wireless 

Local Area Networks Standards Working Group to develop a global standard for radio 
equipment and networks operating in the 2.4 GHz unlicensed frequency band for data rates of 
1 and 2 Mbps. After its introduction; the various versions of the 802.1 1 standard rapidly 
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formed the basis for standardization of WLAN networks and devices in the United States, 
Similar efforts in Europe have evolved around the HIPERLAN standard. 
[0004] Consumers will, naturally, compare services available using wireless 

technologies with services available using wireline service. Wireline services using, e.g., 
Ethernet or Asynchronous Transfer Mode (ATM) protocols provide, among other things, the 
capability to deliver audio and video data across networks. These services have different 
requirements. Audio data, for example, does not require the packet-error reliability required 
of dau* services, but cannot tolerate excessive delay. Video data can in general suffer more 
delay than audio, but is relatively intolerant to delay jitter. These delay and packet-error rate 
considerations may be best supported by a connection-oriented service, wherein the 
parameters are negotiated and established at the commencement of each connection. In 
addition to different types of data, many of today's wireline systems support services which 
provide differentiated quality of service (QoS) levels. 

[0005] In general, the term QoS refers to set of qualitative and quantitative traffic 

characteristics (e.g. throughput, service interval, packet size, delay, jitter, priority, type, etc.)* 
which describes a traffic flow in support of a specific application. In wireline systems, QoS 
issues can be neglected since data rate is very high and the physical layer's error rate is very 
low. However wireless systems incur very high per-packet overhead with limited bandwidth, 
so the same does not apply to wireless systems, e.g., 802.1 1 WLANs. For example, a 
significant percentage of the available data rate in wireless systems is consumed by packet 
fragmentation, interframe spacing and MAC-level acknowledgment. In addition heavy traffic 
load increases collisions and backoffs, so frame delivery time increases further. Frequent 
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retransmissions also cause unpredictable delays on the order of tens to hundreds of 
milliseconds and transmission of pending frames could be blocked. The quality of most 
multimedia services involving voice and video transmission deteriorate dramatically if delay 
increases above certain level. This is a major stumbling block associated with the provision of 
these types of services in wireless communication systems. 

[0006] Accordingly, it would be desirable to develop wireless communication systems 

and methods which reduce delay and provide mechanisms which address QoS concerns in 
order to, for example, provide audio, video and other delay sensitive services 
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SUMMARY 

[0007J* Systems and methods according to the present invention address this 

need and others by providing wireless communication systems that allocate a portion of the 
MAC functionality to a hardware portion of the MAC layer and a portion of the MAC 
functionality to a software portion of the MAC layer- For example, responses to received 
packets having greater QoS-related time sensitivity can be identified and handled entirely 
within the hardware portion of the MAC layer to reduce delay. By contrast, less time 
sensitive MAC processing steps can be performed in the software portion of the MAC layer. 
[0008] According to one exemplary embodiment of the present invention, a method 

for handling data packets in a medium access control (MAC) layer can include receiving a 
data packet, forwarding the data packet to a hardware portion of the MAC layer in a receive 
chain, determining, in the hardware portion of the MAC layer in the receive chain, a packet 
type associated with the received data packet, selectively triggering the hardware portion of 
the MAC layer in a transmit chain based on the packet type; and otherwise, sending an 
indication to the software portion of said MAC layer of the receive chain for generation of 
the response. 

[0009] According to another exemplary embodiment of the present invention, a 

wireless communication device can include a receiver for receiving a data packet, a medium 
access controller (MAC) having a hardware portion and a software portion, wherein a packet 
type associated with the received data packet is determined in the hardware portion of the 
MAC and a receive action table, in the hardware portion of the MAC, having hardware 
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processing functions stored therein for selected packet types, wherein if the packet type of the 
received data packet is one of the selected packet types, then an associated hardware 
processing function is performed and otherwise wherein an indication is given to the software 
portion of said MAC. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] The accompanying drawings illustrate exemplary embodiments of the present 

invention, wherein: 

[0011} FIG. 1 depicts a WLAN system in which the present invention can be 

implemented; 

[0012] FIG. 2 depicts a frame exchange sequence; 

[0013] FIG. 3 shows an interaction between hardware (HW) medium access layer and 

a software (SW) medium access layer according to an exemplary embodiment of the present 
invention; 

[0014] FIG. 4 is a flow diagram illustrating an exemplary method for handling data 

packets in a medium access layer according to an exemplary embodiment of the present 
invention; 

[0015] FIG- 5 is a block diagram of an exemplary WLAN SDIO card, which could be 

inserted into the SDIO slot of the PDA, incorporating an exemplary embodiment of the 
present invention; and ' 
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[0D16J FIG.6 is an exemplary RX Action table according to an exemplary 

embodiment of the present invention. 
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DETAILED DESCRIPTION 
[0017] The following detailed description of the invention refers to the accompanying 

drawings. The same reference numbers in different drawings identify the same or similar 
elements. Also, the following detailed description does not limit the invention. Instead, the 
scope of the invention is defined by the appended claims. 

[0018] In order to provide some context for this discussion, an exemplary WLAN 

system will first be described with respect to Figure 1. Those skilled in the art will 
appreciate, however, that the present invention is not restricted to implementation in WLAN 
systems. Therein, a wireline network 10 (e.g., an Ethernet network) has a file server 12 and 
workstation 14 connected thereto. Those skilled in the art will appreciate that typical wireline 
networks will serve numerous fixed workstations 14, however only one is depicted in Figure 
1 for simplicity. The wireline network 10 is also connected to a WLAN 16 via router 18. 
The router 1 8 interconnects the access points (AP) of the WLAN 16 with the wireline 
network, through which the access points can, for example, communicate with the file server 
12. In the exemplary WLAN system of Figure 1, three cells 20, 22 and 23 (also sometimes 
referred to as a Basic Service Set (BSS) or Basic Service Area (BSA) are shown each with a 
respective AP, although those skilled in the art will once again appreciate that more or fewer 
cells may be provided in WLAN 1 6. Within each cell, a respective AP serves a number of 
wireless stations (W) via a wireless connection. 

[0019] According to exemplary embodiments of the present invention, the 

transmission of signals between APs and respective wireless stations W is performed using 
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wireless communication signals in accordance with one of the 802. 1 1 standards. However, 
those skilled in the art will appreciate that the present invention is not so limited and may be 
implemented for communication of signals in accordance with other formats and standards. 
As mentioned earlier, the introduction of QoS capability into the 802.1 1 standards will result 
in additional time sensitive functionality during a frame exchange sequence to be carried out 
at the MAC layer. To illustrate the time sensitive nature of QoS related frame exchange 
signaling, consider the exemplary frame exchange sequence shown in Figure 2. 
[0020] Therein, a frame exchange sequence between an AP and a first wireless station 

W occurs during a first transmission opportunity (TXOP1). The AP transmits QoS data 
blocks spaced apart from acknowledgements from the wireless station W by short interframe 
spaces (SIFS). A QoS Null message is transmitted by the wireless station W at the last frame 
of TXOP 1 . In order to grant another transmission opportunity to another wireless station W, 
the AP uses the message QoS CF-PolI. Then, during TXOP 2, the other wireless station W 
transmits its QoS data frames to the AP which are likewise acknowledged by the AP. 
Although this example illustrates all data frame transmissions being acknowledged by the 
recipient station, 802.1 le permits MAC level acknowledgements to be optional, i.e., a station 
need not acknowledge a correctly received frame based on the ACK policy field in the 
incoming frame. This further tightens the time constraints associated with data packet 
transmission and reception in such systems since this means that a next package needs to be 
ready for transmission after the SIPS time period has expired. Generally speaking QoS-related 
changes to wireless protocols have introduced time sensitivity in the MAC layer processing 
(1) during data packet reception, when fields have to be extracted, farther software processing 



Codv Drovided hv USPTO from th«* 1FW Imanp na»ahaco nn ftOim/onn* 



9 

has to be done on the data packet or a time sensitive response has to be sent back and (2) 
during data packet transmission, when some fields have to be inserted in the data packet or 
some follow-up action has to be taken. 

[0021] According to exemplary embodiments of the present invention, the time 

sensitivity associated with these, and other, QoS-related wireless protocols can be achieved 
by partitioning MAC level functionality between hardware and software. For example, 
according to exemplary embodiments of the present invention, this partitioning can be 
achieved by a. register interface in the hardware. Due to the varied types of MAC packets 
currently defined for transmission, some of which are shown in Figure 2, and the expectation 
that more packet types will be added in the future in the various standards, MAC hardware 
according to the present invention is designed to deal with the time sensitive nature 
requirement of each type of packet and cater to it as specified by the software. Note that as 
used herein the term "packet type" is intended to include packet types, packet sub-types and 
the combination of packet-types/sub-types. In particular, exemplary embodiments of the 
present invention provide two tables in the MAC hardware, which tables are referred to 
herein as the Rx Action table and Tx Action table. 

[0022] An exemplary high-level implementation of these two tables is shown in 

Figure 3. Therein, an exemplary interaction between the physical layer, hardware (HW)- 
MAC layer and the software (SW)-MAC layer is illustrated. Both a transmit chain 30 and a 
receive chain 32 are shown which can be integrated into a single MAC controller. Note that 
an Rx Action table 34 is included within the HW-MAC layer associated with the receive 
chain 32 and that a Tx Action table 36 is included within the HW-MAC layer associated with 
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the transmit chain 30. An exemplary processing flow for this MAC architecture will now be 
described with respect to the flow diagram of Figure 4. 

[0023] Therein a data packet is first received by a receive module 38 of the physical 

layer at step 50. The data packet is then forwarded to the HW-MAC layer in the receive chain 
32 at step 52. The HW-MAC layer verifies the data packet and determines what type of data 
packet has been received, e.g., from header information, at step 54. The Rx Action table 34 
determines what action to take in response to the received data packet based on its packet type 
at step 56. If the packet type indicates that a faster response is desired, then a trigger can be 
sent directly from the HW-MAC layer in the receive chain 32 to the HW-MAC layer in the 
transmit chain 30. Since this path circumvents the software portions of the MAC layer, the 
resulting response will be faster and less delay will be generated. Examples of data packet 
types and corresponding actions are provided below. If no fast-track response is indicated by 
the Rx Action table 32, then an indication is sent on to the software (SW)-MAC layer in the 
receive chain 32, wherein it is processed and a software (SW>-MAC generated response is 
forwarded to the transmit chain 30 at step 58. 

[0024] Having described an exemplary embodiment for handling data packets in a 

MAC layer according to the present invention, some more detailed examples of Rx Action 
table 34 and Tx Action table 36 will now be provided. The HW-MAC layer in the receive 
chain 32 includes an address filter which determines the destination address of the incoming 
packet which, along with the ACK policy (for QOS frames), is a mechanism for determining 
the set of actions can be taken for this particular packet. The incoming packet can be 
categorized as, for example, one of the following destination types: (1) a packet having a 
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unicast address for this particular wireless station, (2) a packet having a unicast address for 
other wireless stations, (3) a packet having a multicast group address of which this particular 
wireless station is a member, (4) a packet having a multicast group address of which this 
particular wireless station is not a member and (5) a packet having a broadcast address. 
Based on their different destination address types, received frames are treated differently. For 
example, if an incoming frame is intended for this particular wireless station, and if it is 
meant only for this particular station (i.e., if it has a unicast address), then the receiving 
wireless station W shall return an ACK frame to the transmitting wireless station W. 
Alternatively, in case the destination address of the incoming frame is a member of a 
multicast group for which the frame is intended, then the receiving wireless station W should 
not respond with an ACK frame, but should instead be indicated to the SW-MAC layer. The 
same mechanism should be provided to handle incoming frames having a broadcast 
destination address. 

[0025] On the other hand, if the destination address of an incoming frame is a 

multicast address of which the wireless station is not a member, then the frame should be 
filtered out at the HW-MAC layer and should not be indicated to the SW-MAC layer. In 
addition to considering an incoming frame's destination address type, RX Action tables 
according to exemplary embodiments of the present invention also can be indexed according 
to whether an ACK policy field is present in, for example, an incoming QOS frame. 
[0026] Based on this, or other, categorizations of an incoming data packet, the RX 

Action table 34 can be indexed to output an action associated with the determined packet 
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type. Such actions can be represented as bit fields in the Rx Action table entry word and 
include, for example, the following actions. 

[0027] I . Trigger the transmission of a control packet (data packet in the case of an 

incoming CF-Poll frame) which has been preprogrammed. This action can be performed 
when, for example, an incoming packet has is one of the following types: CF-Poll +Data, PS- 
Poll, Data- ACK and RTS-CTS sequence. 

[0028] 2. Trigger an interrupt after a particular number of data packet bytes have 

been received. This action can, for example, be triggered for cases where a new frame type 
is introduced into a standard. The S W-MAC layer will need to act on to be able to operate on 
the new frame type, most likely in a time critical fashion. Thus, when this new frame type is 
received the SW-MAC can enable this interrupt in the RX Action table after, for example, a 
configurable number of bytes were received. 

[0029] 3. Trigger the transmission of a packet following the DCF medium access 

rules. The frames may be queued in the H W-MAC as they are received from the host. The 
HW-MAC layer takes care of sending the frames after following the DCF protocol. This will 
reduce the workload of the SW-MAC and reduce the number of processor cycles associated 
with MAC level processing. 

[0030} 4. Write the incoming packet in memory and generate an interrupt for 

software to process it. This action can be triggered based on destination address filter results 
which indicate that the HW-MAC layer will either write the frame to a memory device where 
the SW-MAC layer can access it. 
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[0031] 5. Perform a CRC check on the incoming packet In some test cases it may be 

desirable to forego performing a CRC check on incoming packets. Providing the trigger for 
CRC checking/not checking in the RX Action table provides an efficient mechanism for 
handling such cases. 

[0032] 6. Update the TXOP holder address. This action can be triggered when, for 

example, an incoming frame is a CF-Poll frame. 

[0033] 7. Update NAV with the duration id of the incoming packet. This action will 

be triggered for many types of incoming packets in the RX Action table. However, the virtual 
carrier sense algorithm associated with the exemplary 802.1 le standard does not need to 
operate on all packet types, e.g., the PS-Poll frame does not have a Duration Id field defined. 
For this reason, the HW-MAC layer should not update the NAV with the 3 rd and 4 th byte of 
the PS-Poll frame, which is generally where the Duration Id is located. The NAV should be 
updated with a remaining CF duration value, if the field is received in the beacon in the 
middle of a CF period. 

[0034] 8. For beacon packets, a number of different actions can be indicated in the 

RX Action table. For example, the beacon can be filtered out beacon based on the BSSID, 
SSID and/or Capability info, the TSF can be updated per the BSS/IBSS update criteria in the 
beacon or the NAV can be updated if the beacon starts a CFP. 

[0035] Similarly, the TX Action table 36 can be organized by packet type/action. 

Based on the packet type/subtype, the TX Action table 36 can be indexed to output an action 
associated with the determined packet type. Such actions can be represented as bit fields in 
the Tx Action table entry word and can include, for example, those set forth below. 
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[0036] 1 . Insert CRC for the packet to be transmitted. This action can be performed, 

for example, for test purposes when it is desirable to validate the receiving wireless station's 
CRC module by receiving a frame for which the CRC has been intentionally garbled. Using 
this option the CRC generation module of the HW-MAC for the transmitting wireless station 
can be disabled. 

[0037] 2. Insert source MAC address/BSSID. Enabling this action in the TX Action 

table may lead to less overhead in the SW-MAC for outgoing frames. This action can be used 
both for the auto-response frames triggered by the HW-MAC in the receive chain, as for 
occasions where the transmitter's and receiver's address needs to be swapped. 
[0038] 3. Fragment the packet based on the fragmentation parameters. The 

fragmentation related parameters can be provided to the HW-MAC which can then take care 
of the fragmentation of the packet without any assistance from the SW-MAC layer. 
[0039] 4. Expect specified response in SIFS time after transmitting packet. This 

may be indicated by the SW-MAC to the HW-MAC when the HWMAC Rx needs to prepare 
the receive state machine for an incoming frame right after transmitting a frame. 
[0040] 5. Generate interrupt(s) upon transmission of packet. This interrupt action 

may be enabled in the TX Action table by the SW-MAC in order to know whether a . 
previously programmed packet has been attempted by the HW-MAC and to provide a 
feedback/result of the attempt. 

[0041] 6. Insert timestamp and/or DTIM count in beacon. This action can be 

triggered whenever the TX Action table receives a packet for transmission from the SW- 
MAC layer. 
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[0042] Those skilled in the art will appreciate that the foregoing example, which 

refers to the 802.1 le standard, is purely illustrative and that the present invention can be 
applied to communication systems which operate in accordance with other standards. 
Readers who are interested in operations of 802.1 1 and/or 802.1 le are referred to the IEEE 
Standard for Information Technology, Part 1 1 : Wireless LAN/MAC and Physical Layer 
(PHY) Specifications, ANSI/IEEE 802.1 1 (1999) and the Draft Supplement to the IEEE 
Standard for Information Technology, Part 1 1 : Wireless LAN/MAC and Physical Layer 
(PHY): MAC enhancements for Quality of Service (QoS), ANSI/IEEE 802,1 le/D4.0, 
November 1 999, both of which are expressly incorporated here by reference. 
[0043] The allocation of MAC functions between hardware and software according 

to the present invention can be provided in any wireless communication system or device. To 
further illustrate the present invention, an example is shown in Figure 5 with respect to an 
embedded wireless LAN chip in a PDA device. Therein, an exemplary MAC controller 60 
(ASIC chip) is illustrated which includes a general purpose microprocessor 62, at least one 
memory unit 64, a HW-MAC unit 66 and an SDIO interface unit 68. Those skilled in the art 
will appreciate that other functional blocks, e.g., a DMA controller, other I/O ports, a power 
converter, additional memory devices, etc., can be included however only these four 
functional blocks are depicted to simplify the discussion. The HW-MAC ASIC unit 66 
communicates with a transmitter and receiver (not shown) and includes the RX Action table 
and TX Action table described above. According to exemplary embodiments of the present 
invention, those packet types received by the HW-MAC ASIC chip 66, and identified in the 
RX Action table as designated for expedited response and/or other hardware action, are 
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handled within HW-MAC ASIC chip 66. For example, if HW-MAC ASIC chip 66 receives a 
CF-Poll packet, its RX Action table may specify that an automatic, prestored response be 
retrieved from memory 64 and sent to the transmitter for transmission without involving the 
general purpose microprocessor 62 in this part of the process. Notwithstanding an indication 
in the RX Action table to perform a certain HW-MAC action on an incoming packet, there 
may also be pay load data to be processed by the general-purpose microprocessor 62 and, for 
example, output via SDIO interface 68 to the wireless PDA device. 
[0044] A more detailed example of an RX Action Table according to the present 

invention is provided as Figure 6. Therein, the rows specify the various packet types that can 
be received by the MAC. The columns represent the actions which the HW-MAC is capable 
of performing. This table can be translated into a 64-bit register in the HW-MAC where the 
HW-MAC indexes on, for example, the 02-07 bits of the incoming packet. The HW-MAC 
uses theses bits to determine what kind of address type is associated with the incoming packet 
and then takes the corresponding action as specified in the corresponding RX Action table 
bits. The 64 bit register may be designed in such a way that a group of bits (corresponding to 
an action required) are allocated to the 'Unicast Self address class, others to the 'Multicast 
self address class and like wise for the 'Multicast others', broadcast and 'Unicast others' 
address class of the incoming frame's receiver address. . The functionality associated with 
the Special Action column in Figure 6 according to this exemplary, but purely illustrative, 
embodiment is described below in Table 1 . 



17 



C1 


Beacon can be either Broadcastfthen Drocess^ or notfit is ionored in which case it is an 
invalid packet) 

1) Parse the beacon to note the origin of the beacon (IBSS or BSS). In case it is from an AP 
and this wireless station is a member of this BSS then update the TSF value of this wireless 
station with the TSF in the beacon, in case it is an IBSS beacon and this wireless station is a 
member of this IBSS then update only if the value of TSF in beacon is greater than this 
wireless station's TSF value. In all other cases ignore the TSF value in the beacon. 

2) update NAV if the CF Parameter element starts a CFP; and 

3) generate receive indication to the SW-MAC. 


C2 


The address of RR and CC are BSSID. Matching result can be either "self or "other". 


WO 


Send CTS if NAV—O, otherwise, ignore. 


C4 


For CTS Unicast self, HW MAC should send pending fragment or MSDU automatically. 


C5 


Continue sending the next frame if this was not the last frame. Otherwise, generate a 
transmission status Indication to the SW-MAC. 


C6 


If this wireless station is CF-aware then do not generate any interrupt to the SW-MAC but 
update the NAV. 


C7 


Store the TXOP Holder address. 


C8 


Auto send QoS ACK or ACK (as configured by the SW-MAC).. 


C9 


1) Do the decryption if WEP bit— =1 ; and 2) generate a receive indication to the SWMAC. 


C10 


Auto send CF-ACK/ACK if required and generate Receive Indicate interrupt. 
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C11 



1) Store the TXOP value in the TXOP register; 

2) Check whether a QpS Data frame has to be sent In response. If not then send the 
QOS Null frame; and 

3) In case there is QOS data frame to be sent in response to a +CF-Poll frame then 
fetch the data frame from the predefined memory location and send it. 



Table 1 

[0045] The above-described exemplary embodiments are intended to be illustrative in 

all respects, rather than restrictive, of the present invention. Thus the present invention is 
capable of many variations in detailed implementation that can be derived from the 
description contained herein by a person skilled in the art. From the exemplary Rx Action 
table of Figure 6, it can be seen that the SW-MAC layer enables particular feature(s) in the 
HW-MAC on initialization. Accordingly, in order to suit varying architectures a particular 
option may be disabled or enabled in the HW-MAC layer. If disabled, then that functionality 
will either be carried out in the SW-MAC or eliminated. Thus, the present invention's 
provision of Rx/Tx Action tables provides flexibility in the e.g., ASICs, with respect to 
frequent changes in communication standards. All such variations and modifications are 
considered to be within the scope and spirit of the present invention as defined by the 
following claims. No element, act, or instruction used in the description of the present 
application should be construed as critical or essential to the invention unless explicitly 
described as such. Also, as used herein, the article "a" is intended to include one or more 
items. 
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WHAT IS CLAIMED IS: 

1 . A method for handling data packets in a medium access control (MAC) layer 
comprising the steps of: 

receiving a data packet; 

forwarding said data packet to a hardware portion of said MAC layer in a 
receive chain; 

determining, in said hardware portion of said MAC layer in said receive chain, 
a packet type associated with said received data packet; 

selectively sending an indication directly to a hardware portion of said MAC 
layer in a transmit chain based on said packet type; and 

otherwise, sending an indication to a software portion of said MAC layer of 
said receive chain for generation of said response. 

2. The method of claim 1, wherein said step of selectively sending said response 
based on said type-subtype of said data packet further comprises the step of: 

sending said response to said hardware portion of said MAC layer in said 
transmit chain if said packet type is one of: CF-Poll, PS-Poll, Data/Management- - 
ACK and RTS-CTS. 

3. The method of claim 1 , wherein said step of determining said packet type 
further comprising the step of: 
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determining a destination address of said data packet using an address filter. 

4. . The method of claim 1 , wherein said step of selectively sending a response 
directly to said hardware portion of said MAC layer further comprises the step of: 

providing a receive action table in said hardware portion of said MAC layer in 
said receive chain, wherein said receive action table is indexed using said packet type 
to output said response. 

5. The method of claim 1 , wherein said hardware portion of said MAC layer is 
implemented in an application specific integrated circuit (ASIC). 

6. The method of claim 1,. wherein said software portion of said MAC layer is 
implemented in a general purpose microprocessor. 

1, The method of claim 1, further comprising the steps of: 

receiving another data packet, from said software portion of said MAC layer, 
for transmission; 

providing a transmit action table in said hardware portion of said MAC layer 
in said transmit chain, wherein said transmit action table is indexed using said packet 
type to output a function for said hardware portion of said MAC layer to perform on 
selected packet types and destination address type; and 
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selectively performing said function based upon a packet type of said another 
data packet. 

8. The method of claim 7, wherein said function further comprises the step of: 
inserting a cyclic redundancy check (CRC) for said another data packet. 

9. The method of claim 1 , further comprising the step of: 

✓sending, as said response directly to said hardware portion of said MAC, an 
interrupt after a predetermined number of bytes have been received. 

1 0. A wireless communication device comprising: 

means for receiving a data packet; 

a medium access controller (MAC) having a hardware portion and a software 
portion, wherein a packet type associated with said received data packet is determined 
in said hardware portion of said MAC; and 

a receive action table, in said hardware portion of said MAC, having hardware 
processing functions stored therein for selected packet types; 

wherein if said packet type of said received data packet is one of said selected 
packet types, then an associated hardware processing function is performed and 
otherwise wherein a response indication is forwarded to said software portion of said 
MAC. * 
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1 1 . The device of claim 1 0, wherein if said packet type is one of: CF-Poll, PS- 
Poll, Data/Management- ACK and RTS-CTS, then sending a response directly via 
said hardware portion of said MAC. 

12. The device of claim 10, further comprising: 

an address filter, in said hardware portion of said MAC, for determining a 
destination address of said data packet. 

13. The device of claim 10, wherein said hardware portion of said MAC is 
implemented in an application specific integrated circuit (ASIC), 

14. The device of claim 10, wherein said software portion of said MAC is 
implemented in a general purpose microprocessor. 

15. The device of claim 10, further comprising the steps of: 

a transmit action table in said hardware portion of said MAC, wherein said 
transmit action table is indexed using said packet type to output a function for said 
hardware portion of said MAC layer to perform on selected packet type-subtype; and 

wherein said hardware portion of said MAC selectively performs said function 
based upon a packet type when another data packet is forwarded for transmission by 
said device. ... 
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16. The device of claim 15, wherein said function further comprises: 

inserting a cyclic redundancy check (CRC) for said another data packet. 
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ABSTRACT 

Systems and methods according to the present invention provide 
communication systems that reduce delay associated with packet transmission. Selected 
MAC functions are performed directly in a hardware MAC layer rather than being forwarded 
to a software MAC layer for processing. There is flexibility in carrying out a function either 
in the HWMAC or S WMAC based on what actions have been enabled for HWMAC. This 
can accommodate design changes in the solution and ever changing standard requirements. 

Figure 3 for publication. 
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